The money ledger: one billing profile per organization — currency and method — and the invoice lifecycle from issued through due, overdue and paid. THB for the reference organizations; the currency always comes from the profile, never assumed. A generic subdomain — a commodity capability, a candidate to buy.
Billing owns the profile and the invoice — nothing about pricing (Tenancy's plans) or deal value (Sales). Won-deal drafts arrive by event; RiverSync accounting issues and reconciles. Partner visibility into agreement-related invoices is a scope switch on the Coverage grant, resolved like every other partner read.
Reads from: Tenancy (organization, currency at bootstrap) · Sales (won deals to invoice). Account is the customer surface; Admin the RiverSync one.
The words this context uses — the same in code, conversation and spec.
The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.
How this context meets its neighbours — downstream customer/supplier of Sales (won deals to invoice) and Federation (profile bootstrap).
The deployment mapping: this context becomes the Billing service. Paths relative to api.riversync.com/v1; access notation per the master.
The past-tense facts this context publishes (and consumes) — its share of the platform's published language.
The modeling rules that bind this context — the master holds the full set; data integrity stays with the ERD drill-downs.
| Version | Date | Changes |
|---|---|---|
| 0.1 | 12 Jun 2026 | First draft — split proposed with SPEC-DDD v0.1 |
| 0.2 | 28 Jun 2026 | Reframed as a Domain-Driven Design context (with the set, SPEC-DDD v0.14) — leads with ubiquitous language & aggregates (BillingProfile, Invoice) and the context relationships (customer/supplier downstream of Sales). Classified a generic subdomain; the API is demoted to the physical view. No ownership change. |